The order of these is roughly in order of importance and dependency. The first two should make the OTrunk system easier for new developers to get a handle on.

• add plugin support to views so they can be extended with sub views they don't know about.

• attempt to remove ResourceSchema inner classes, replace the ResourceSchema with an interface, and replace the current OTObject with a wrapper object, or view. This is good for a few reasons:
  • makes external manipulation of the OTrunk object easier.
  • it is a step towards an emf implementation of OTrunk
  • this will not work in all cases. There are some cases where having code in the OTClass is very convenient.
    • to address this cleanly, we need to have generated java code, or use bcel or script to extend abstract classes.
    • this is needed for service implementations, for example the view service is used to setup views, so if we try to replace resource schemas with views and interfaces this view service would have to be an exception because it can't serve itself.

• merge wrapper objects and views. these two features are really the same thing, just being used in two different ways. A wrapper object is really just an object view of a model.

• extend view service to support views implemented by OTrunk objects instead of only java objects. This will open up the possibility of view implementations using template languages (velocity), scripting languages (javascript, jruby), form languages (xform) or a custom otrunk form languague.

• implement an xml view. This could be used to pass a dom tree representation of a particular root object to an xml viewer, or editor. This could eventually be a replacement for the xmldatabase. This comes out of the following logic:
  1. we want to move to emf or something like it, which can store the otrunk state directly in java objects.
  2. this removes ability to maintain the object state in a single place outside the objects.
  3. but we want to maintain the ability to store and manipulate the objects as an xml tree or as in a relational database.
  4. the manipulation part of this is basically what a graphic view of the objects does. So the same view architecture can be used.

1. 1. the idea of loading a set of otrunk objects in from an xml view is the same as the desired loading of otrunk objects from a pre constructed set of wrapped objects which are also views.

• implement a custom form view. This requires the extended view service above. The form would specify form controls for editing properties of an otrunk object. This is very similar to xforms. Basic (primitive) properties are easy, because we have controls for them. But object, list, and map, properties do not yet have controls. Probably multiple types of controls will be needed. One example is the multiple graphable view. This essentially is a control for handling lists. An object property could have its form view embedded, with the ability to find and select another object instead.
  • A first application of this would be to implement a way to author sensor data graphs directly in the OTViewer

• add support for combining multiple files together: either imports, or url based reference ids. The latter is the approach taken by EMF. There is currently support for multiple files, by making a separate database for each and then using the UUID of the database to reference the object, then the OTViewer just needs to open both files. But that isn't very easy to extend.

• implement very simple document editor that allows insert of existing objects, and creation of new objects. This is most useful after the custom form view is implemented.

• analyze the service setup, examples of services are the view service, and the interface manager. This analysis will be best informed after the plugin arch is finished.